home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / networking / 3333 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.4 KB

  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.networking
  4. Subject: Re: Announce: AWeb 1.0 released!
  5. Date: 1 Apr 1996 19:37:33 +0200
  6. Organization: dis-
  7. Message-ID: <4jp48t$akq@serpens.rhein.de>
  8. References: <4joodb$74d@walrus.megabaud.fi>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. petrin@walrus.megabaud.fi (Petri Nordlund) writes:
  12.  
  13. >  If rendering just means drawing the decoded images, then it
  14. >  doesn't matter. But things like scrolling the document and
  15. >  opening other windows like hotlists etc. must not be slowed
  16. >  down by this.
  17.  
  18. It isn't slowed down by this because it is not "rendering".
  19.  
  20. >  Ok, but why should rendering and decoding slow down network I/O?
  21.  
  22. Just because something _has_ to become slower when the machine spends
  23. 100% of the CPU. Simple math.
  24.  
  25. >>That's what AWeb does, although it runs the threads at the same fixed
  26. >>priority of 0.
  27.  
  28. >  Which doesn't make much sense because image decoding slows down
  29. >  everything else.
  30.  
  31. It doesn't slow down the GUI and it _should_ slow down rendering of the
  32. pages.
  33.  
  34. >  You must remember that when the decoder task
  35. >  is running and you click on a gadget, the main task is not
  36. >  waked up immediately, Exec will let the decoder task run for
  37. >  a full quantum.
  38.  
  39. Which isn't a problem. The quantum is small enough.
  40.  
  41. >  The result is that the main task gets LESS
  42. >  than 50% of available CPU time to handle the GUI and user input.
  43.  
  44. Not really. It just gets less when it needs less. If it needs several
  45. timeslices for an action then it is timesliced like any other CPU-intensive
  46. process.
  47.  
  48. >>And this is something you do not need. Why should rendering stop decoding ?
  49.  
  50. >  Let's say you are scrolling the display, why should decoding make
  51. >  scrolling slower?
  52.  
  53. Scrolling is a job of the user-interface and not rendering a page.
  54.  
  55. >>We have threads, thank you. And no, most systems schedule threads.
  56.  
  57. >  We have LWPs (Light-Weight Processes), not real threads.
  58.  
  59. Obviously we have, one thread per task.
  60.  
  61. >  We need user-level threads run as a single process.
  62.  
  63. You mean that we need multiple threads or tasks to be scheduled as a group.
  64.  
  65. >  All threads
  66. >  share the same address space and are scheduled by a selectable
  67. >  thread-scheduler.
  68.  
  69. All threads/tasks in the Amiga share the same address space.
  70.  
  71. -- 
  72.                                 Michael van Elst
  73.  
  74. Internet: mlelstv@serpens.rhein.de
  75.                                 "A potential Snark may lurk in every tree."
  76.